Background #

I participated in an AWS Threat Detection and Response Workshop aimed at providing an overview of the security tools available within AWS. Now I have some experience securing AWS workloads, and throughout my career I’ve seen companies leverage a number of third party tools to help with this, and I’ve never really dug too deeply as to why. Why is it that there’s so many additionaly security tools in the market (CIEM, CSPM, CWPP, CNAAP, etc.), and what use-cases are folks running into that the native tools aren’t enough? In attempting to answer the prior questions, at least in the context of threat detection and response, my hope is that I can then understand what value all these third party tools actually provide you. Now in my experience this type of review was already done for me, but I did want to understand the scenarios where using what AWS has given you is not enough.

To try and answer these questions I first needed to understand how AWS wants me to use their security tools, so I refreshed myself on the AWS Security Reference Architecture.

Overview of AWS SRA and Security Tools #

The AWS SRA gives perscriptive guidance for how AWS intends organizations to deploy multi-account environments, that adhere to their Well Architected Framework. The way I understand it, it’s a bit like the product picture on a lego box. It gives you an idea of how all of the different services (lego pieces) were intended to fit together. Understanding the SRA was useful, as it helped me see the big picture for the various aspects of Cloud Security an organization should have covered, and the services/tools AWS provides for you to get there. Overall, the SRA wants you to set up your Org with a dedicated Org management account, a security tooling account to aggregate findings and manage tools, a log archive account for storing logs, infrastructure accounts to manage networking and shared services such as Active Directory and lastly workload accounts where you’ll deploy applications too.

Some of the tools/services aimed at helping you with threat detection and response include:

• AWS Security Hub (Cloud Security Posture Management)
• AWS GuardDuty (IDS/IPS)
• AWS Inspector (Vulnerability Scanning)
• AWS Detective (Security Analytics and Forensic Investigation)
• AWS Security Lake (Security Data Lake as a Service)
• AWS Macie (Data Loss Prevention and Sensitive Data Discovery)
• AWS Config (Configuration Management)
• AWS CloudTrail (AWS API action logging)
• AWS CloudWatch (Monitoring and Observability)
• AWS Secrets Manager and AWS Key Management Service (Secrets Management and Encryption)
• And so many more…
• Whole slew of tools to either extend or integrate these tools including: Lambda, SSM, EventBridge, etc.

Detect, Investigate, Respond and Remediate #

Here’s a quick general overview of how you might leverage the tools discussed above to carry out basic security operations:

Detect #

• Leverage GuardDutyto detect actions taken by resources which indicate compromise
• Use AWS Inspector to identify where you have vulnerabilities
• Leverage AWS Config, CloudTrail, VPC Flow Logs, etc. to detect abnormal changes to infrastrucutre, AWS API calls or traffic
• Aggregate this findings from all of these tools into Security Hub and security lake

Investigate #

• Leverage Security Hub as a single pane of glass to see where investigation is warranted
• Speed up analysis using AWS Detective
• Correlate detection findings with additional logs found in your security lake - query the data using Macie or AWS Opensearch

Respond and Remediate #

• For common or critical findings automate response/remediation by integrating Security Hub with EventBridge and trigger Lambda or Systems Manager Documents to triage systems, or pull additional context automatically

For more details on this please see AWS’s documentation. It’s very well written. For the remainder of the post I will assume you have some familiarity with the SRA and .

So where does all this start to break down? #

So I want to say that for smaller organizations that are just using AWS these tools and the SRA is really helpful to get you moving in the right direction. They even provide you with Infrastructure as Code templates to provision infrastructure based on the SRA. That being said, below are some of the scenarios where these things might not be enough.

Multi-Cloud and Cross Cloud Governance #

After you hit a certain scale, or you go mutli-cloud or are hybrid-cloud just using the AWS tools will leave you blind to threats in your other environments. For example, AWS Macie isn’t going to show you what data you’re storing in your Azure Blobs, and then your team needs to make a decision to either maintain seperate tooling for the two environments or purchase a dedicated Data Security Posture Managment (DSPM) SaaS product to manage both - in which case third party tooling might make sense. Obviously, a lot goes into that decision, but tool consolidation factors in.

Deep Compliance/Audit Coverage #

The basic checks that AWS Config and AWS Security Hub give you would not be enough to prove you are complying with controls required by certain regulations or Certifications/Standards such as HIPAA, ISO 27001, etc. You can either build out a lot of custom checks to do this, or invest in a CSPM that can make it easier to ensure infrastructure remains compliant as they do some of the heavy lifting for you.

Advanced threat models and workload specific hardening #

The native tooling isn’t enough to provide endpoint security. A dedicated EDR or Runtime Protection tool might be beneficial here to provide additional hardening. Also, if you’re a high value target, like a managed service provider, it is more likely that nation state actors will want to target you. Therefore, having more stringent controls may be necessary, which may require either additional tooling and/or going beyond the SRA’s recomendations.

Enter Identity Governance and Administration (IGA) #

Existing IGA solutions don’t seamlessly extend to cover cloud-specific permission models. So to tie this into the audit coverage point, if an auditor comes to you and asks show me all users who can modify production data in S3 buckets containing customer financial information, an IGA isn’t going to be able to do that because it’s not going to understand the interplace between SCP’s, IAM Policies, resource based policies and permission boundaries. So governing identities in the cloud may be better handled by a Cloud Infrastructure Entitlement Management (CIEM) tool.

Closing thoughts #

In general for AWS-only shops and smaller organizations the native tools might be good enough, but as organizations grow and complexity increases bringing in additional tooling might prove more cost-effective/reliable than building out/maintaining custom solutions.

If I got anything wrong, or you want to discuss anything from the above post please feel free to reach out. All of my preferred communication channels are listed under the home page.